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FOREWORD 


This final report, prepared by Martin Marietta Denver Aerospace, 
provides the technical results to the Space Station Automation Study. The 
report is submitted In volumes: 


Volume 2 - Technical Report 


These documents are submitted in accordance with the requirements of 
contract NAS8-35 rt 42. They reflect the work performed under task 5.3, "Space 
Station Automation Study", for the George E. Marshall Space Flight Center of 
the National Aeronautics and Space Administration. 

Martin Marietta personnel involved in this study effort and who 
attributed t » this report are as follows: 

K. Z. Rradf ord-Documentation Manager, Technology Assessment 

P. C. Daley-Computer Architecture, Artificial Intelligence and 
Systems Automation 

W. H. Chun-Assembly and Construction 
D. L. Miller-Systems and Referral Data 

Comments or requests for additional information should be directed to: 

Jon Haussler 

Contracting Officer's Representative 
George C. Marshall Space Flight Center 
Huntsville, Alabama 35812 
Telephone: (205)453-4955 


OR 


Richard A. Spencer 

Program Manager 

Martin Marietta Aerospace 

P.0. Box 179 

Denver, Colorado 80201 

Telephone: (303)977-4208 
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1.0 INTRODUCTION 

1.1 PURPOSE 

The purpose of the Space Station Automation Study (SSAS) was to develop 
Informed technical guidance for NASA personnel in the use of autonomy 
and autonomous systems to implement Space Station functions. 

1.2 GENERAL APPROACH 


The initial step taken by NASA in organizing the SSAS was to form and 
convene a panel (Figure 1-1) of recognized expert technologists in 
automation, space sciences and aerospace engineering to produce a Space 
Station automation plan. 



Figure 1-1 SSAS Organization 


As Indicated on this schematic, California Space Institute (CSI) was 
assigned the responsibility for study management. A Senior Technical 
Committee, chaired by Dr. Robert Frosch, was appointed to provide 
overall technical guidance. 
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A NASA Technology Team was convened to produce focused technology 
forecasts, supporting panel analyses, and system concept designs. 
Stanford Research Institute (SRI) International was assigned to this 
team. 


A NASA Design Team was also convened to produce Innovative, 
technologically-advanced automation concepts and system designs 
supporting and expressing panel analyses. The emphasis of this effort 
was to strengthen NASA understanding of practical autonomy and 
autonomous systems. Four aerospace contractors— General Electric (GE), 
Hughes Aircraft Company (HAC), TRW and Martin Marietta Corporation 
(MMC, Denver Division Aerospace) — were assigned to this team. Halfway 
through the study, a fifth contractor, Boeing Aerospace Company (BAC), 
was also assigned to this team. 


A work breakdown for the original four contractors was assigned as 
shown in Figure 1-2. The fifth contractor, Boeing, was assigned to 
investigate and report on man-machine interfaces. 
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Figure 1-2 SSAS Work Breakdown Structure 
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1.3 MMC OBJECTIVES 

Martin Marietta's assigned study responsibility covered two specific 
and significant areas relating to projection of a futuristic Space 
Station and the type of scarring necessary for evolutionary implementa- 
tion. The two basic objectives of the MMC effort were: 

a) Define through analysis the potential ultimate conceptual design of 
the Space Station systems to the highest level of automation that 
can be perceived to be accomplished by circa 2000. Specifically, 
this involved the overall system and selected subsystems 
(environmental control and life support, electrical power and 
information and data management). In a parallel effort, Hughes 
Aircraft Company addressed the other subsystems. 

b) Define through analysis the system-level applications of automation 
technology for assembly, construction, repair and modification of a 
Space Station and its various elements. 

The system automation was conceptualized at circa 2000, then backed 
toward the Initial Operational Capability (IOC) space station. 
Conversely, the assembly and construction technologies were built on 
IOC reference concepts, then extended from IOC to circa 2000. 

1.4 BACKGROUND 

The Space Station concept currently conceived encompasses both manned 
and unmanned operations. A crew of six to eight flight personnel will 
be employed in various tasks where past experience indicates a strong 
need for human presence. 
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The application of automation to Space Station Is a topic of great 
current Interest and controversy. At the extreme ends of this 
controversy is the tradeoff of a total autonomous system versus a highly 
human activity intensive system. Two major issues within this 
controversy are: 1) does the incorporation of automation significantly 

reduce the "cast of thousands" on the ground?; and 2) does technology 
availability push or mission requirements pull the autonomy technology? 
Many approaches are available to address these issues; however, a better 
understanding is required of future goals, interactions, and impacts. 

It is apparent that future space systems will be required to remain 
operational for 20 years and longer. Over this life cycle, they will be 
required to adapt to constantly evolving and challenging requirements. 
Both systems and subsystems need to deal with this reality in the best 
possible way. One method used successfully on prior programs is to use a 
form of long-range planning through futuristic forecasting. Long-range 
planning is a keystone to providing flexibility, productivity and life 
cycle cost improvements. 

A timely issue is how to project the future missions and define which of 
the associated operational functions would be better satisfied by 
automating a few or many of the subsystems. This future insight provides 
the capability to build in or "scar" the IOC Space Station for later 
adaptation to evolving technology. 

The challenge is to define a Space Station that combines the proper mix 
of man and machine, while retaining a high degree of backup capability 
with ease of growth. 
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2.0 APPROACH AND GUIDELINES 


2.1 MMC STUDY APPROACH 

Figure 2-1 shows the study task flow organized Into five main 
activities or thrusts for the assigned MMC study areas: 1) Summary of 

Space Station 2000 (plus) Tasks and Activities, 2) Perceived Highest 
Level of Automation, 3) Assessment of Automation, 4) Identification of 
Automation Needs and Time Plans, and 5) Presentation, Documentation and 
Sustaining Engineering support. 

A special feature of this flow Is the parallel focus of the Space 
Station system automation and the space assembly and construction 
automation. The tasks were designed and organized to meet the study 
objectives in a timely manner. 
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Figure 2-1 Approach to Space Station Automation Study 
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As shown In the Study Flow Plan (Figure 2-1) , there are five major task 
areas. The results of each task effort feed into and provide the basis 
for the following task work. By following this disciplined approach, 
each task area should receive the proper emphasis to provide meaningful 
results. 

The basic approach was further structured in a matrix format in which 
both the automated systems assembly and construction activities were 
directed through each of the five major tasks in a parallel manner. A 
brief description 1 of the activities Involved in conducting the major 
tasks is presented in volume 2, along with the work breakdown structure 
and definition of terminology, acronyms and abbreviations. 

2.2 GUIDELINES 

The guidelines used to bound this study and to provide focus and 
direction are listed below: 

a) Maximum use was to be made of related government-sponsored space 
automation studies. 

b) The associated lead time needed to prepare the technology base and 
to perform the necessary advanced development activities was 
estimated to be four to five years. 

c) In addition to the Manned Maneuvering Unit (MMU) and Remote 
Manipulator System (RMS), an Orbital Maneuvering Vehicle (OMV) and 
Orbital Transfer Vehicle (OTV) would be available to support 
orbital construction and assembly operations. 

d) The Space Station mission requirements identified by NASA/LaRC, 
dated 7 June 1984, would be used as a representative mission model 
where practical. 

e) A power tower concept with gravity gradient stabilization would be 
used as a Space Station configuration focus. 

The emphasis of these guidelines was on the role of automation 
technology and its projected evolutionary growth out through the year 
2000 and beyond. 
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3.0 SIGNIFICANT STUDY RESULTS AND RECOMMENDATIONS 


3.1 SIGNIFICANT STUDY RESULTS 


The complete output of this study effort is Included In the Final 
Report, Volume 2, Technical Report. Some of the more significant 
results and observations have been collected, summarized and presented 
herein. 

a) Large Space Structure Commonality — Four different space structure 
configurations were assessed during this study. While the basic 
configurations differed- 1 the principles of assembly and 
construction were found to be similar. As a result, many of the 
assembly and construction support equipment (ACSE) items defined 
were common Irrespective of the particular space structure 
configuration. 

b) ACSE Configuration — Based on results of this study and some of 
the prior studies there is a general trend in material and 
personnel handling mechanisms. For example, both long booms and 
small dexterous manipulators were found to have a major role in 
autonomous orbital construction. The long boom provides a reach 
capability and a transport path for the material supply function, 
while the small manipulator provides dexterous physical activities 
similar to those required for small parts assembly. 

c) Man’s Involvement — Man's involvement in the construction process 
starts with an intensive involvement (EVA and teleoperation) and 
slowly decreases until he provides only a contingency capability. 

An evolving work shift and task responsibility philosophy as a 
function of risk, productivity and cost should be established. 
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d) Construction Aids - Additional emphasis should be placed on the 
use of flexible jigs, fixtures, and scaffolding in the construction 
of large space systems. In many cases, these items would be 
similar in size as the large space system structure but in general 
would be stiffer, built to close tolerances, inherent alignment 
capability, alignment references, and location references. Since 
these aids provide a basic support platform for the ACSE, the ACSE 
requirements are dependent on a number of interrelationships. 
Constructions aids and ACSE interfaces relevant to fixed, mobile 

and portable types should be investigated for impacts. 

* 

e) Orbital Construction Equipment — The need for interactions between 
orbital construction equipment, assembly/construction support 
equipment, and operational maintenance equipment is apparent. 
Interactive parallel studies addressing on-orbit automation in 
these areas should be initiated. 

f) Operational Maintenance — After completion of constructing a large 
space structure, the ACSE is available to move on to the next 
construction site to start a new project. However, the ACSE 
currently envisioned is aptly suited to perform operational 
maintenance activities. This role along with the number of units, 
serviceability, availability and control mode should all be 

investigated. ! 

I 

i' 

g) Simulation — New simulation techniques will be required for 
large-scale space operations, i.e. assembly, construction, repair, 
modification, disassembly, etc. Major factors to consider include 
space simulation in one-"g" environment, scaling of structures, and 
predictive models. In many cases an historical knowledge base must 
be initiated in conjunction with computer aided engineering and 
design (CAE/CAD) at the program start and maintained and updated 
throughout the program life. 
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h) Flexible Assembly — It Is very apparent that any space operation 
that Is basically a replace or assembly activity should consider 
flexible assembly. This can be accomplished through simple 
guidelines that address issues such as access to and from orbital 
replacement units (ORUs), common/manipulator compatible attachment 
fasteners, multiple grip/hold points on ORUs, and labeling 
compatible with both humans and machines. 

i) Design Challenge — While it may be apparent, this study has time 
and again discovered the importance of good design. There is 
nothing inherent in certain technologies which will obviate the 
need for good design - especially in the data management system. 

It is possible to have a well designed keyboard based man-machine 
interface outperform a poorly designed voice interface. 
Consequently, abstract issues such as functional structure or the 
relationship of functional architecture to physical architecture 
becomes important. 

j) Data Management — The data management system is pervasive and 
will be complex. Its ability to tolerate faults, assess its own 
state, and function under a variety of transient loads will be 
key. It should be seen as a command and control system as opposed 
to a mission sequencer and data storage system. The two are very 
different. Command and control relates to the presence of software 
more highly integrated with human users, and consequently more 
complex. 

Experience with such systems in the DOD arena shows that designing 
for growth and evolution are an absolute necessity - there is no 
way that the requirements for such a system can be known completely 
a priori. This will require significant overdesign and careful 
examination of underlying protocols such as timeslicing to project 
their adequacy against several space station growth scenarios. 
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k) Exploitation of Artificial Intelligence — The space station must 
accommodate large quantities of artificial Intelligence technology 
on ground, In experiments, on board as part of the system, and In 
the development tooling enabling Its definition and development. 
While this Is an arena of some risk, It has high payoff as well. 

It can allow significant workload reduction for the crew as well as 
Increased safety. The stabilization of the process by which AI 
technology Is developed Is at the base of Its risk. Inclusion of 
AI development into a properly tailored engineering method would 
have high payoff. 

3.2 RECOMMENDATIONS 


Based on Investigations and discussions presented during this study and 
the Initial study objectives to Identify and define automation 
candidates, a number of ACSE and system architecture were outlined 
along with recommended follow-on design, technology development, 
fabrication and testing. 

a) Supporting Research and Technology — Key technology areas were 
Identified for each of the selected ACSE. A summary listing of 
these technologies along with a priority ranking is shown below: 

o Teleoperation 

o Proximity, Touch, and Force Sensors 
o Predictive Displays 
o Low Weight-Dexterous Arm 
o Dual Arm Coordination 
o Advanced Activators 
o Knowledge Based Systems 
o Planners, Strategic and Tactical 
o Expert Systems 
o Machine Vision 

o Special and Multi-Finger End Effectors 
o Multi System Coordination 
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In many of the Items Identified above a number of similar or identical 
technology concerns were associated with more than one ACSE. These 
overlapping key technologies can be investigated in single studies 
covering requirements that address the spectrum of ACSE technologies. 
The results of this prioritization were intended to show trends rather 
than exact conclusions. 


b) Automation Growth Impacts on Space Station IOC — The overall 

emphasis of this study was to project into the future and forecast 
initial requirements needed to adapt to future uncertainties. The 
incorporation of flexibility into all phases of the program helps 
in planning for many of the future uncertainties. One cost 
effective approach is to Incorporate a structured and modular 
technology implementation capability. Some of this capability can 
be achieved by including early in the program design and build 
phase a number of "scars'* that aid in future station modifications , 
and growth. A brief summary of the major "scars" proposed are: 

ACCESSIBILITY: Design access ‘’corridors to allow for growth MRMS and 

working envelopes at selected worksites. 

BERTHING: Provide additional berthlng/docklng ports at multiple 

locations throughout the Space Station. As the 
program matures , the number of free flyers will 
increase, i.e., stowed or crippled. 


HARD POINTS: Design system to have "hard" or rest points at 

worksites to aid in stabilizing manipulator end 
effector motion. Hard points located at structure 
nodes provides considerable flexibility to many other 
A&C activities. 
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LABELING: Labeling , marking, or coding of all modules, 

assemblies, and components with viewing access Is 
required for replacement operations. Marking or 
coding the complete Space Station Into 3-D grid Is 
needed for early autonomous robots with machine vision. 

MODULARIZATION: Modular design of all systems and subsystems should be 

a primary Space Station ground rule to accommodate 
growth, servicing, and updating. Module (ORUs) should 
have replacement Interfaces compatible with EVA and 
manipulators. 

STOWAGE: Much of the A&C support equipment, i.e., small tools, 

materials/parts, etc. Look at providing holes In 
structural surfaces to accommodate temporary Item 
attachments. Also consider for mobility (crawling). 

KNOWLEDGE BASE: Establish and maintain a process for "skill" or 

"knowledge” retention where knowledge and experience 
of experts working the Space Station program would 
codify their expertise and lessons learned into 
inference rules of a KBS for future use in an expert 
system. 

TEST PORTS: Design test ports into the data management system to 

accommodate autonomous checkout and troubleshooting 
capability of a mobile robot or intelligent servicer. 

c) Fault Tolerance and Redundancy — Major subsystem computers should 
make use of fault-tolerant techniques. These processors should be 
sized to allow adequate throughput performance In spite of the 
fault tolerant processing overhead. Key computers should have 
backup or redundant processors. 
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d) Functional Encapsulation — Within the data management system the 

need for communicating software processes should be kept to a 

mini mum. Efforts should be made to keep the processes which do 

communicate residing within the seme processor. Some limited 

number of optimization or simulation programs may require parallel 

operation running on different processors but they should be kept 
* 

to a minimum. Further the bus Interface units should be 
significantly overdesigned to accommodate an Increase In subsystem 
activity. 

e) Status /Warning System — There should be a status and warning 
system to aggregate the state of the space station and provide the 
crew with advice. This component can also function as a mission 
control surrogate from the ground If the space station becomes 
Isolated . 

f) Knowledge Based Systems (KBS) — The space station should be 
designed to accommodate KBS on board. The need for a development 
environment to support the knowledge engineering and domain 
modeling for the space station Is apparent. KBS should be used to 
monitor and advise. Techniques to fluently Integrate knowledge 
bases and conventional software should be developed. 

g) System Performance Prediction — The space station data management 
system needs extensive performance prediction modeling to validate 
the design concepts. Specifically, data bus loading, time slicing 
plans. Inter-process communication, and access to peripheral memory 
are Important. 

h) System Automation Growth Impacts — The scarring or IOC design 
aspects and prioritization needed to accommodate the system 
automation techniques derived from this study are shown In 
Table 3-1. 
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Table 3-1 Scarring and Prioritization 


SCARRING 


- SUBSYSTEMS USING FAULT TOLERANT COMPUTERS 

- ADEQUATE SIZING OF PERIPHERAL MEMORY ACCESSIBLE 
ON THE ODDNET 

- EFFECTIVE USE OF TIMESLICING FOR MEMORY ACCESS 

i- ACCOMMODATION OF 32-BIT PROCESSORS IN THE SDPs 

- SIGNIFICANT OVERDESIGN OF ID UNITS (BASED ON 
EXTENSIVE PERFORMANCE MODELING) 

- ABILITY TO ADD AT LEAST ONE NEW SUBSYSTEM TO 
THE ODDNET 

- ACCOMMODATION OF TOP-LEVEL ADVISOR 

- ENFORCEMENT OF FUNCTIONAL BOUNDING WITHIN 
THE HIERARCHY 

- PROVISION OF A DEVELOPMENT SYSTEM FOR GROUND 
BASED KBS DEVELOPMENT 

- EXTENSIVE USE OF MISSION TEMPLATES MAY DRIVE UP 
PERIPHERAL MEMORY REQUIREMENTS 

- CAREFUL INTEGRATION OF KBS WITH STANDARD SOFTWARE 
AND DATA BASES 


PRIORITIZATION 

PERIPHERAL MEMORY ACCESS 
TOP-LEVEL ADVISOR 
DEVELOPMENT SUPPORT TOOLS 
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4.0 SYSTEM AUTOMATION 


There are several goals for automation on the Space Station, as shown 
in Table 4-1. Automation may reduce crew workload or, stated another 
way, could allow more complex tasks to be performed by the crew at 
constant work levels. Automation could allow the Space Station to be 
less dependent upon ground telemetry, tracking, and control. This 
would allow the Space Station to survive if cut off from the ground for 
an extended period of time. This decreased ground dependancy could 
allow select payloads to be flown during Space Station development 
prior to a fully operational crew staffed station. This relates to 
earlier return on investment. 

Automation could significantly reduce the number of ground personnel 
necessary to run the mission. The reduction would not be so much in 
the area of mission operations and direct support, but rather in the 
"standing army" of support personnel. This would be a cost saver for 
the government and again lead to an earlier return on investment for 
the government. 


Table 4-1 Goals of Automation 

AUTOMATION GOAL AFFECT PAYOFF 


0 

Reduce crew workload 

0 

Increase number 
& complexity of 

0 

More revenues 

o 

Allow more complex 
crew activities 


payloads 

0 

Lower user cost 

o 

Less ground dependancy 

0 

Select payloads 
flown sooner 

0 

More revenues 

0 

Longer time between 

0 

Assure SS will 

0 

Reduced risk of 


TT&C 


attain its life 
expectancy 


mission failure 
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0 

Less ground personnel 

o 

Limit mission 

o Cost savings 


than otherwise would 


support staff 



be needed 


costs 


0 

Less training of a 
mission staff separate 
from STS 




0 

Testbed for American 

0 

Space Stations 

o Strengthen our 


industry 

0 

Underwater Systems 

high technology 
competitive stance 



0 

Flow-down to 
commercial side 
of technology 



4.1 FUNCTIONAL CHARACTERISTICS 


4.1.1 General 


It was attempted to establish the ultimate attainable level of 
automation for the Space Station circa 2000. While somewhat unclear, 
this point in the evolution of the Space Station becomes an important 
study tool. The expected IOC was then analyzed to determine what were 
logical and reasonably manageable steps to take towards the maximal 
automation configuration were then evaluated. 

This portion of the study dealt with Space Station systems. It is 
assumed that: 

o The computer and software across the subsystems was a key accommo- 
dator of automation. 

o The design of the computer and software, considered as a system, 
was crucial to allowing the highest levels of automation, 
especially Intelligent automation. 
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o The portions of the Automatic Data Processing (ADP) system which 
perform mission elements , now thought of as ground-based and 
complex, are what provides the context for the stepping from IOC. 
o Those portions of the ADP deal with planning and scheduling, and 
caution, warning, and status monitoring. 


Therefore, the functional components of the ADP were analyzed, the 
logical steps from the ultimate back to IOC were established, and the 
technology that could improve feasibility was considered. The approach 
may be summarized by the following set of sequential study objectives: 


o 

o 

o 

o 

o 


Conceptualize 2000+ information system architecture 

Establish ultimate levels of automation 

Conceptualize design sufficient for those levels 

Show phased stepping towards ultimate automation levels 

Is the system design which accommodates high automation levels 

reasonable? 


4.1.2 Data Management System 

As an example, Figure 4-1 shows the data management system (DMS) and 
its corresponding subsystem specific components. There are two avenues 
to approach automation. The first is referred to as hard automation 
and those aspects of the DMS shown in the hard automation column can 
affect Space Station autonomy. The second column, intelligent 
automation, refers to the newer field of using knowledge based system 
(KBS) techniques. The elements of that column are some key issues 
discussed herein. While the study involved issues and subsystems other 
than these, those shown are considered important. Refer to Volume 2 
for the other subsystem discussions. 
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Figure 4-1 Elements to be Implemented on Space Station ADP 
4.1.3 Development Process 


A large portion of the work focused on what tools and techniques would 
be necessary to support the development of the Space Station, Adequate 
tooling in the area of software and systems development support can 
make the difference between success and failure of a software intensive 
system. Often, two important facts are missed: first, tools must be 
ready and relatively stable in advance of the application need date; 
second, the investment in tool development may be larger than the cost 
to develop a system component through the use of that tool. 

However, the tools can be applied over and over to, in this instance, 
space systems. Further, some key problems one must overcome to build a 
tool specific for the Space Station are generic to a wide number of 
applications throughout American industry. Tools are clearly produc- 
tivity accelerators, 

4.1.4 Summary Conclusions 

The space station provides new and challenging problems for NASA, Some 
of these problems have been attacked by DoD and industry; however, 
integrating previous work with a space station acquisition as well as 

commencing new solutions will be major. 
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The expected life of the space station as well as the desire for Its 
autonomy and efficiency force the data management system to act like a 
co mma nd and control system. Its function will be mode sequencing and 
data collection, but, also, will be the support of human cognitive 
processing. Requirements for such decision support systems are fuzzy 
and changeable. The use of evolutionary acquisition as a formal stra- 
tegy has proven successful with the DOD. Each system version is seen 
as a prototype of subsequent systems. There Is an Intentional abandon- 
ment of the goal of specifying the complete requirements set a priori. 
Instead, careful long-range design analysis must be instituted. This 
results in seemingly over-engineering the Initial versions of a system 
so as to minimize the likelihood of design inadequacy later. 

a) Crew as Decision Makers - With increased use of microprocessors, 
graphic displays, and automation, the role of the crew appears to 
be shifting from that of controller and flight engineer (attitude 
and systems monitor) to that of manager and decision maker. Inter- 
actions between crew members and systems will change. 

b) Command and Control System - The problem here is how to configure 
microprocessor and multi-function display systems to enable crews 
to assimilate information readily and effectively. 

c) Subsystem Status Monitoring/ Caution & Warning - One additional 
function per subsystem is anticipated and one corresponding 
additional computer to process that function. The need for 
symbolic processors among these additional computers is 
anticipated. Communications system sizing will likely be adequate 
if local storage either through RAM discs or Winchester based 
peripherals is provided. The system should be designed so as not 
to preclude the inclusion of 32-bit processors in the standard data 
processors (SDP). 

d) Development Support - The need for adequate software tooling and 
laboratories should be respected. Some of these are shown in Table 
4-2. 
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Table 4-2 Development Support Needs 


o Software Prototyping and Development Environment 

o Test for Distributed Systems 

o Intelligent Validation & Verification 

o KBS Development Environment 

o Test for KBS 

o VLSI Design Aids 

o VLSI Transition Laboratory 


4.2 CONCEPTUAL DESIGN 

The design aspects are based on the ADP elements, shown in Figure 4-1, 
to be implemented on Space Station. 

4.2.1 Hard Automation 

Of the two paths toward automation, the most familiar are those 
techniques which are immediate extensions of current system design. 
These include the physical architecture, the philosophy of process 
control/coordlnation, and functional allocation to an executive. Some 
supplemental areas on a less abstract level are also relevant to space 
station. These include fault tolerance pnd redundancy, smart sensors, 
and built-in test. Aspects of these are discussed as they relate to 
Space Station Automation below. 

4. 2. 1.1 Physical Architecture - The space station will make use of a 
hierarchical distributed physical architecture for its ADP . Such 
an architecture has achieved success in real-time process control; 
and, properly designed, provides reasonable flexibility. The Space 
Station IOC workbook adopts this approach. The ability to have 
subsystem busses is important to being able to interconnect the 
necessary computers. 
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If the Standard Data Processor (SDP) discussed In the IOC document 
allows for 32-blt processors and the optical data distribution network 
(ODDNET) and Interface device (ID) are sized accordingly, the IOC 
physical architecture should suffice. The architecture is shown In 
Figure 4-2. A distributed system offers processing flexibility, 
expandability without redesign and, generally, size and weight 
advantages . 


LEGEND: 

S&E- Sensors and 
Effectors 
SDP- Standard 
Data 

Processor 
GN&C- Guidance 

Navigation and 
Control 

COM- Communications 
HAB- Habitation 



Figure 4-2 Physical Architecture- Information and Management System 

4. 2. 1.2 Control Philosophy - A reasonable way to view the organization of the 
functional architecture is hierarchically. This is useful from at 
least two perspectives. The first deals with the context of 
analyzing possibilities for automation. The architecture arranges 
functions so those most akin to higher level human cognitive 
processes are in the center. Those most removed are correspondingly 
representative of less complex cognitive processes. The second 
reason for such an arrangement is the flexibility of the structure. 
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As the functional definition of the Space Station moves forward, It 
will be easy to map the Identified functions to the arrangements. 
Systems may be added or deleted from a level or levels changed. Such 
a mapping will not Invalidate the analysis of automation 
possibilities discussed herein. 

4. 2. 1.3 Role of the Executive - An executive, in the sense of a master 
computer from which all commands originate, will not be needed on the 
Space Station. The current notion is that each subsystem will 
provide a service, in response to mission demands. The crew and 
ground control will initiate missions and the specific subsystems 
will respond accordingly. As such, there Is no need for an executive 
in a control sense. There is, however, a need for a preferred system 
whose function Is to aggregate system state from subsystem state 
Information. This system could be ground based Initially and flown 
later or could be part of the crew command and control software. A 
preferred subsystem, such as the ». .tus monitoring, caution and 
warning system, is recommended. 

4. 2. 1.4 Fault Tolerance and Redundancy - An example of the technique expected 
to be found adequate for most redundancy applications is cross 
connection. The secondary may be on hot or cold standby. The 
primary periodically stores a snapshot of its state in the shared 
memory for checkpoints. When the controller responsible for managing 
this redundant set determines that the primary is faulty, that 
responsible controller disables the primary and enables the 
secondary. Some of the elements to be considered in redundancy and 
fault tolerance are shown in Table 4-3. 
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Table 4-3 Redundance and Fault Tolerance Considerations 


o All major subsystems 

o Redundancy of all major subsystem computers 
o Self-checking and correcting 

- Error detection/correction (hamming) for memory 
transient faults 

- Spare physical memory for permanent memory faults 
Second microprocessor for state errors 

Third microprocessor for permanent hardware fault 


4. 2. 1.5 Built-In Test - While fault-tolerant computer architecture will be 
used in key subsystems, they will not be found in every subsystem. 
Subordinate processors and systems will have the ability to status 
what is controlled and to inform the appropriate controllers of 
errors. Fault-tolerance Implies the ability to detect and correct 
errors within a processor. Built-in-test refers to the ability to 
detect errors within subsystems. It Implies either the existence of 
a microprocessor tightly integrated with a subsystem or a software 
program running in a subsystem controller. 


4. 2. 1.6 Smart Sensors (Integrated) - The effect of smart sensors is to allow 
a partitioning of basic controller functions between the intelligence 
within the sensor and within the system controller (Table 4-4). This 
could eliminate the basic controller in some instances, but the 
viability of this approach depeuus on the computing capability 
included with the sensor. Adding computational capability to sensors 
introduces the potential to eliminate basic controllers entirely. 
Thus, some savings might accrue. 

Table 4-4 Smart Sensors 

o Microprocessors integrated with sensors 
o Pattern recognition in the associated microprocessors 
o Signal conditioning functions in the microprocessors 
o Weight and power savings likely a wash 

o Frees higher level controllers to run other functions - control 
push-down 
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4.2.2 Intelligent Automation 

4. 2. 2.1 Mission Templates - It should be possible to rigorously pre-analyze 
all normal, routine mission elements of the Space Station. The 
results of this analysis can be captured In tables of states, lists 
of procedures, and menu based templates. During the execution of 
mission element, data points obtained at the subsystem level can be 
compared to the appropriate state vectors and control exercised In 
accordance with the pre-loaded constraints and rules. The mission 
template generation and execution process is illustrated in Figure 
4—3. There may be significant application of AI technology in 
designing the minimal state vector/control set to prestore. 


State 

Vectors 



SETTING UP THE PROBLEM 



EXECUTING THE MISSION ELEMENT 


Figure 4-3 Mission Template Generation and Execution 
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4. 2. 2. 2 Operator System Interface (OSI) - The OSI should use stand-alone 
capable 32-bit processors in the class of Sun or Apollo. Their 
existing interface tools are flexible and general, providing multi- 
windowing and ICON accessible objects, as well as bit-mapped displays. 

Some system modeling tools could be hosted on the OSI computers. 

These could Include mathematical models of subsystems or 
table-oriented subsystem state computers. The class of machines 
discussed above provide significant computational and I/O 
capability. Further, data collection and trend analysis software may 
be hosted on the OSI computer. This would aid in solving the 
knowledge engineering problems for specific subsystems at a later 
date. Considerations are summarized in Table 4-5. 


Table 4-5 OSI Considerations 


o Use stand-alone capable 32-bit processor (Sun, Apollo) 
o Host some modeling software on MMI computer 

o Host data collection for trend analysis software on MMI computer 
o Weight differences will be negligible 
o Power differences may be become important 
o Data system sizing probably will be adequate 
o Human Factors Friendliness requires additional processing 

- "Modeless” interface 

- Models of human interaction 

- Strive for a graphics (ICONIC) input language 


4. 2. 2. 3 Onboard Software Support Environment - The ideal, tailored software 
environment applicable to the onboard systems probably does not 
currently exist. It should Include a compiler for the language that 
is to be used for all software executing on the station. It should 
also include a text editor that is sensitive to the syntax of the 
language so the editor can help the programmer catch errors and 
enforce rules for structuring programs. The environment should hide 
from the programmer any dependencies introduced by the level of con- 
troller, which is the target upon which the software is to execute. 
The host computer, upon which the development environment executes, 
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should provide enough run-time facilities to allow the programmer to 
debug code without having to download Into the target controller until 
late In the debug phase. Such software development environments are 
under development for the ADA programming language. Development 
considerations are shown In Table 4-6. 


Table 4-6 Software Development Environment 


o Single HOL for entire space station 
o Single HOL for space station life 
o ADA may be too Immature 

- lack support environment 

- compiler development currently lagging 
o Consider "C" 

- good for operating system development 

- tailorable 

solid support environment, UNIX 
supports KBS development 

o Require rapid prototyping or testbed aids for preliminary checkout 


i 


f- 

I 

4. 2. 2. 4 Top Level Advisor - In contrast to the mission template approjich^to 

automation, there is need for, eventually, a top level advisor. This 
system would be a subsystem of the space station and reside on Its 
own interface device to the ODDNET. Likely it would have several 
computers each with significant amounts of main and peripheral 
storage, all preferably solid state. If the space station is to be 
autonomous from the ground, it needs a subsystem whose function is to 
act as ground surrogate. While mission templates would allow subsys- 
tems to know what to do for a mission component, the top level 
advisor would plan and schedule mission components. Figure 4-4 shows 
the components of such a system. CPCI refers to a computer program 
configuration item and CPC to a computer program component. 
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Figure 4-4 Components of Top Level Advisor 


4. 2. 2. 5 Knowledge Based Systems Subcomponents - Scattered throughout the 
space station software will eventually be KBS components. They will 
be used for system fault detection/isolation and for embedded status 
monitoring. The fundamental structure will Involve a sequence of 
sensor /actuator, A/D conversion, state comparator, rule base Inter- 
pretation; and, if necessary, conflict resolution through a knowledge 
base. At lower levels In the system, very little dependence will 
occur on the knowledge base. Once fixed, the state comparator and 
rule base will be accessed most often and this activity is similar to 
data base access. They will be mechanized as tables within a data 
base. The KB will run best on a symbolic processing machine. The 
other components can be run on normal computers. The higher in the 
functional hierarchy one moves, the more complex and Important 
becomes the KB. 

4. 2. 2. 6 Data Basa Effects - There are two aspects to data that are generally 
confused in everyday discourse between humans but which become 
Important in software design. These two aspects are intenslonal and 
extenslonal, as shown in Table 4-7. Intenslonal data captures the 
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meaning or Intent of data objects. It may be considered data about 
facts. Eztenslonal data focuses on descriptions of processes or 
world objects. An example of eztenslonal data Is a description of a 
maintenance procedure whereas the lntenslonal data would provide an 
explanation of why parts of the procedure are being done. 

Knowledge based systems focus on the lntenslonal aspects of data and 
require data bases containing lntenslonal Information. Control 
systems focus on the eztenslonal aspects and require data bases 
containing eztenslonal Information. Both kinds of data base will be 
present In the space station. It will be Important to be able to 
coordinate between these data bases. More specifically, one cannot 
expect to use an eztenslonal data base for lntenslonal based 
lnferenclng or vice versa. It would be difficult and wasteful of 
effort to duplicate eztenslonal data within an lntenslonal data base. 


Table 4-7 Data Base Effects 


NOTE: In human activities, we generally mix these- two aspects of data. 


INTENSIONAL 

Meaning 

Data about facts 
Meta-models 

EXAMPLE : 

Explanation of why parts of the 

PROCEDURE ARE BEING DONE 


EXTENSIONAL 

Description 

Facts 

Models 

EXAMPLE : 

. Description of a maintenance procedure 
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4.3 AUTOMATION ASSESSMENT 

4.3.1 Comparison of Automation Techniques 

Figure 4-5 shows each of the automation techniques considered. 
Generally, the hard automation techniques can all be Implemented In the 
near term. Some of the Intelligent techniques which focus on use of 
conventional software approaches but requiring extensive analyses of 
the problem domain are ready. In a future time frame (5-10 years) the 
knowledge based techniques could be ready as well as highly Integrated 
sensors with extensive pattern recognition software. Much of the hard 
automation approaches apply to low level system components while the 
Intelligent approaches affect higher level components. Technology risk 
for the hard automation techniques Is low and becomes high for the top 
level advisor. 


But the?, i are roles for each automation approach, and the knowledge 
based techniques should not be Ignored just because they Involve some 
techrdcal risk. Payoff Is In the areas of fault tolerance/ 
redundancy;' built-in test, mission templates, top level advisor, and 
KBS subcomponents as they directly affect crew workload and autonomous 
operations. Certainly, the hard techniques should be Implemented for 
near term payoff. The intelligent techniques should be Implemented as 
well and the KBS approaches commenced as soon as possible to drive 
their maturation. 
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Figure 4-5 Summary Comparison of Automation Techniques 
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4.3.2 Assessment Dlacuaalon - The scarring or design aspects needed to 

accommodate the automation techniques are summarized In Section 3.0. 

It Is clear that the space station must accommodate fault tolerant 
computers at the subsystem level as well as redundant computers hosting 
key processes. As fault tolerance makes use of Hamming codes the 
subsystem computers should be oversized to mitigate the expected 
performance degradation. The use of peripheral memory accessed through 
the ODDNET Is reasonable. Sizing of that store, can become Important 
depending on functions and data allocated to It. This points to the 
need for extensive performance prediction simulations. 

A corresponding Issue concerns effective use of timeslicing to provide 
memory access and subsystem-subsystem communication. There are many 
aspects to this Issue. Depending on how the tlmesllcing Is enforced 
and designed, the data management system can be biased towards 
synchronous or asynchronous operation. This In turn could cause 
significant data use of the bus. The SDPs should accommodate 32-blt 
processors. This allows use of virtual memory operation and can also 
serve to mitigate some of the performance degradation caused by 
fault-tolerant approaches . 

A Significant overdesign of the bus Interface units (BIU) or Interface 
devices (ID) should be provided. Again, significant performance 
modeling Is required to support this analysis. Inadequate sizing of 
these units (speed) could severely affect throughput In the system. 

There should be provision to add at least one major subsystem to the 
ODDNET after IOC. This is envisioned as the top-level advisor. Within 
the functional architecture of the space station, functional 
encapsulation or bounding to the maximal extent should be enforced. 

This will minimize data flow in the system and allow easier maintenance 
and upgrade of the software. 
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The KBS components will need a ground-based development machine 
separate from mission control computers. This machine should run LISP 
and/or PROLOG In firmware and host the necessary development support 
tools. The KBS, when stable, will be moved onto target architectures 
which will run on the ground. Extensive use of mission templates 
onboard may drive up peripheral memory requirements so that RAM discs 
and other solid state local storage is Inadequate. Further, hosting 
mathematical modeling and/or data collection and organizing software on 
the machines could impact peripheral memory requirements. Local disc 
or bubble memory peripheral storage may be needed. 

... The Issue of Integrating KBS with standard software and data bases Is 
Important. Stand-alone ’’expert systems" cannot be afforded nor are 
they needed. KBS techniques must be exploited in conjunction with 
conventional techniques, viewing each of these as merely ways of 
encoding intenslonal knowledge. 

The issues Involved In adequate development support cannot be ignored. 
The Investment in tooling is crucial, as it allows management of 
complex software. Note that 1) solution of problems in constructing 
tools should occur well in advance of the need date of the tools, and 
2) that such tools when constructed can be applied throughout American 
industry. Refer to Volume 2 for details concerning the development 
support needs. 

4.4 TECHNOLOGY DEVELOPMENT PLAN 

4.4.1 Staged Implementation (Top Level Advisor) 

It would be plausible to consider a staged approach to providing the 
ultimate configuration of space station data management systems. 
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Initially all knowledge based systems will be under development on the 
ground In a machine optimal for development of such software , possibly 
In approximately 1990. The ground personnel would provide the 
functions previously described to be performed by a top level advisor. 

The next logical step would be to host the various top level advisor 
and subsystem KBS on their target architectures. The subsystem 
components will be hosted on board as elements of the Standard Data 
Processors (SDPs). The top level advisor would likely require several 
computers sharing a local data bus. One of these computers would 
likely be a symbolic processor much like a SYMBOLICS 3600. An 
additional likely computer for the top level advisor would be a data 
base machine such as an IBM 500. It is an open question whether large 
peripheral storage of data necessary for the top level advisor is best 
kept locally or accessed through the ODDNET. This Issue would be re- 
solved after the peripheral storage requirements are established. The 
functions running on these machines on the ground would perform as ex- 
periments. Ground personnel would still be prime for such missions 
elements. 

The next step would rove the subsystem components on board during the 
next three years, to be in place by about 1995. During such time, the 
crew would monitor closely the activities of these components. During 
this period careful attention will be paid to the standard mathematical 
optimization and modeling software supporting calculations of 
schedules, docking maneuvers, resource expenditure, etc. Ground 
personnel would still be prime. A key question will be to what extent 
versions of these models can be Integrated with the top level advisor. 
It Is desirable to have this conventional planning and predicting 
software available to allow mathematically trying out KBS systems. 
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A short time after this stage, (1996), It should be possible to move 
the top level advisor's target architecture onboard the space station 
as a separate subsystem being off the main space station data bus. It 
would require Its own Interface device and SDP. During this time It 
would be run as an onboard experiment; ground personnel would still be 
primary for the top level advisor missions. 

By 1998, It should be reasonable to expect the onboard crew to perform 
planning, scheduling, and status monitoring functions with the help of 
the top level advisor. This date could be significantly Improved upon 
from, say, 1996 If there are no development problems nor any 
significant knowledge engineering problems. 

Finally, by 2000, the space station onboard systems would Include fully 
Integrated top level advisors and subsystem components. These would 
function In the mode of supporting the human crew to the extent they 
wished and managing the space station when cut off from ground or 
without crew. Preliminary analyses show that there should be little 
Impact on data communications within the space station through 
Inclusion of these systems - presuming adequate local data storage 
accessibility, without tasking the main data bus. 

4.4.2 Top Level Advisor Automation Approach 

The top level advisor will consist of several portions that could 
ultimately be implemented as shown in Figure 4-6. The figure lists the 
top level advisor element In the far left column, its proposed computer 
processor needs, the degree of complexity of the automation process, 
what form that automation will take, and some typical comments at the 
far right. 
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Figure 4-6 Attainable Automation Levels 


4.4.3 Cooperating KBS Components 


Figure 4-7 points out both where advances in techniques for making use 
of various artificial Intelligence and conventional software techniques 
In a cooperative manner are required and where some cooperation may 
occur. Except for natural language Interfaces, the components column 
of the figure, orders the technologies by speed of execution. ' It Is 
noted where complexity and size factors Impact the components. The 
technology needs, where known, appear in the right-hand column. 
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Figure 4-7 Structural Attributes of Al Technology Base 


One can envision how these technologies could cooperate. The learning 
and prediction systems could run in "background" mode to the deep 

reasoners, forming hypothetical world models and long-range predic- 

/ 

tlons. The deep reasoners could run in a similar support mode for 
planners. The deep reasoner could pre-analyze options and validate 
candidate plans. This would require a loose coupling between the two. 
Planners could perform a similar function for expert systems by embed- 
ding their results in a time and event ordered structure and therefore 
evaluating those results. 


4.4.4 Time Phasing of Needs \ 

If both product, e.g., systems onboard space station, and development 
process support needs are arranged by time, one can get an idea of the 
extent to which some of the automation' approaches may be implemented. 
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Figure 4-8 shows this arrangement, focusing on key examples. 

Initially, proof of concept expert systems, planner experiments, and 
deep reasoner experiments are all running on the ground. In the 
mid-1990s at least one onboard symbolic processor and some onboard 
expert systems for fault detection/diagnosis are anticipated. At about 
2000, large stable expert systems, fast planners and some learning 
systems, all onboard, are expected. There will be several symbolic 
processors and extensive cooperation between the KBS components. By 
IOC, test aids for distributed systems, and KBS, plus space station 
specific VLSI design aids, and a KBS development support environment 
are needed. 
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, — ry 
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Figure 4-8 Overall Placement of Automation Needs by Time 

Well before IOC a stable comprehensive software support environment for 
the selected space station language Is needed. This Is another reason 
to consider alternatives to ADA. ADA may be ready in 2-3 years for 

J 

system development but it is unlikely a comprehensive support en- 
vironment will be ready for 5 years or more. In the mid-1990s, 
semantic linkers and Intelligent validation and verification tools are 
needed. This is all quite feasible. 
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During the parallel parts of the SSAS effort, space station automation 
features and definitions were achieved along with identification of 
corresponding assembly and construction support equipment. A brief 
definition for each concept was generated by collecting and organizing 
relevant data for all four reference structures as to basic . 

configurations, assembly construction scenarios and functions!'”''"’"”" 
activities. In addition, a spectrum of A&C elements were defined for 
large space structures and the evolutionary shift in the assembly and 
construction process from man intensive to machine Intensive. 


Assembly and construction support equipment (A.CSE) characteristics were 
established by assessing a finite set of generic processes that applied 
to one or more of the four reference large space structures. The 
functional flow shown in Figure 5-1 provides a task sequence and 
references the paragraphs herein where each step is discussed. 


5-1.1 An.t'/ses 



Figure 5-1 Functional Flow of ACSE Assessment Process 
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5.1 FUNCTIONAL CHARACTERISTICS 

The initial step used in developing ACSE functional characteristics was 
to review and select a representative assembly and construction mission 
set that would encapsulate both near- and long-term technology needs 
for a wide range of potential users. The objectives in guiding the 
selection process were to produce a conceptual configuration and system 
description that could be both manageable and broad enough to uncover 
and display major construction and assembly functional issues where 
automation could have a considerable Impact. The detail desired should 
be top level but sufficient to typify major technology drivers involved 
in evolutionary changes required over an operating period of 10 to 20 
years . 

The major focus was placed on starting with the IOC Space Station 
buildup and on specific areas where automation could play a beneficial 
role in operational productivity and safety. Using this approach, four 
categories and specific missions within each were identified as shown 
in Table 5-1. 


Table 5-1 Selected A&C Mission Model 


MISSIONS 

YEAR 

o ASSEMBLE IOC SPACE STATION 

— Power tower or strongback & common modules 

1991 

o EXPAND SPACE STATION 

— Add satellite servicing facility 
— Add OTV hanger and service facility 

1992-1994 

o ASSEMBLE LARGE SPACECRAFT 

— Assemble LDR at Space Station (LM-3) 

1997 

o ASSEMBLE GEOSTATIONARY PLATFORMS 

— Advanced Large Commercial Communication Sys. (LM-7) 

LM — Landmark Mission 

LDR — Large Deployable Reflector 

OTV — Orbital Transfer Vehicle 

2000 


Features of the mission model concepts address NASA's role in 
initiatives to exploit and explore space over an evolutionary period of 
time. ^ Characterization of the major features include visibility to an 
extended operational time span, using a starting point where 
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considerable resources have already been expended, using operational 
orbltB where both manned and unmanned activities have been Identified 
and verified, using basic structural configurations that are compatible 
with a number of generic type large space structures, and using 
missions that have been evaluated from both a deployable and erectable 
standpoint . 

As a summary of the assembly and construction model's Implications for 
long-term technology applications and needs, It serves potentially as a 
"quick look mission set" In the form of an assessment tool. Its use In 
this effort was to develop or Identify commonality trends, starting 
with the IOC Reference Configuration and going out through construction 
of a geostationary (GEO) platform. This time flow has a direct utility 
to technology planning with possibly a much greater cost impact on 
technology Implementation, i.e., integrate or bypass. The Introduction 
here of a very limited uumber of missions and system concepts used to 
Illustrate the application of derived technology utilization and needs 
was a function of the time available to do the study. However, general 
results from many of the prior relevant studies that have examined 
specific missions In considerable detail Indicate that the mission 
uniqueness and state-of-the-art implementation have the greatest impact 
on design conceptualization. ( 

5.1.1 A&C Mission Scenarios 


The majority of effort expended on these four missions was focused on 
the IOC Space Station buildup with considerable lesser effort directed 
at the other three. 

The basic options available to the mission designer is the selection 
between deployable and erectable or some mix of both. Program impacts 
of these options are many and in some cases very significant. Primary 
selection drivers are based on transportation costs, material density 
and costs, cargo bay stowage efficiency, degree 
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of on-orblt versus ground fabrication, flight crew versus ground 
personnel time and quantity and complexity of orbital construction 
support equipment. Where special equipment Is Identified, It, In turn, 
has special functional requirements. This equipment may have to be 
assembled, positioned, set up, controlled, monitored, serviced and 
maintained with specially-trained personnel or servicer equipment 
located at the construction site. The special equipment Identified to 
perform these types of functions has been classified as Assembly and 
Construction Support Equipment (ACSE) . Present indications are that 
many diverse support equipments will be required, and although the 
specific equipment may be dependent on the nature of the large space 
structure system to be constructed, the basic principles of 
construction are such that much of the support equipment Is common. 

This equipment commonality factor was stressed throughout the study 
effort, along with Its adaptability toward technology transparency. 

Seven Shuttle flights shown In Figure 5-2 have been identified to make 
the basic IOC Space Station operational. The structure utilizes a ,f 
combination of deployable and erectable structures with the majority of 
the booms and keels deployed automatically. 

Figure 5-3 Illustrates a typical section of an automatically deployable 
Box Truss structure (A) along with an example of an erectable "Nested 
Tube” (B) structure. 

Advantages and disadvantages between these two examples are many and 
conflicting, e.g., packaging for delivery to orbit and on-orbit 
operational support have opposite advantages and disadvantages for the 
two examples show in Figure 5-3. 
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In the Space Station reference documentation, a mobile remote 
manipulator system (MRMS), shown in Figure 5-4, is the major piece of 
assembly and construction support equipment used to move people and 
material over the Space Station structure. The basic unit consists of 
a crawling mechanism and a Shuttle remote manipulator. 



Figure 5-4 MRMS Reference Configuration 

The scenarios and functional activities discussions on the remaining 
three representative A&C missions are presented in the technical report. 

5.1.2 ACSE Commonality 

An initial listing of common, generic ACSE is shown in Table 5-2. This 
list is a combination of items identified in the four reference 
missions, with duplications combined and less significant items 
omitted. Many of the potential candidates are obviously significant 
and require much further detailed analysis. 


I 
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1) 

Shuttle Remote Manipulator (RMS) 

11) 

Universal Tool Storage Unit 

2) 

Mobile Remote Platform 

12) 

Portable a Mobile Lighting/ 

3) 

Mobile Remote Manipulator System 


Camera Unit 


(MRMS) 

13) 

Portable Control Box/Pendant 

4) 

MRMS with 2-20 ft Arms (RMS 

14) 

Special Function Manipulators 


Derivative) 


(5-DOF or less) 

5) 

Telepresence Work Effector (EVA 

15) 

Carousel Mechanism (satellite 


Analog) 


ASSEM, FIX) 

6) 

Mobile Foot Restraint (MFR- 

16) 

Structure Deployment Aid 


shuttle) 

17) 

Alignment a Surface Accuracy 

7) 

Closed-Cherry Picker 


Tools (Gross) 

8) 

Universal Docking (Berthing) Unit 

18) 

Alignment a Surface Accuracy 

9) 

Fasteners (inherent in design) 


Tools/System (Fine) 

10) 

Fastener Tools (clamp, weld, 

19) 

Checkout Tools 


rivet, etc,) 

20) 

Portable Deployable Sun Shade 


21) Special Purpose End Effectors 


(Manipulator 

Exchange) 


5.2 CONCEPTUAL DESIGN FOCUS ON MRMS 


The Mobile Remote Manipulator system (MRMS), sometimes referred to as 
the Assembly and Transport Vehicle, is a multipurpose logistics device 
outfitted with a space crane (Shuttle RMS). As shown on Figure 5-4, it 
plays an Important function in the buildup of the Space Station IOC and 
is the primary logistic tool on the station. The system is a tool to 
transport modules and/or payloads from the Shuttle cargo bay and 
position them for attachment to the Space Station truss structure. The 
combination of crane, astronaut and Manned Maneuvering Unit (MMU) are 
utilized in locating, latching and deploying the structure segments. 

The same procedure is repeated for the radiators , the keel extensions 
and the lower boom. Subsequent usage is necessary for maintenance, 
repair and servicing of the station and future spacecraft. It is also 
necessary for Space Station growth and assembling spacecraft. 
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5.2.1 MRMS Evolution 


Figure 5-5 shows a summary of the anticipated MENS program evolution as 
It applies to an automation assembly growth of Space Station. 

All of the original IOC capabilities will also be available throughout 
this span. In 1993 two 20-foot arms will be added and additional 
control capabilities incorporated, as shown. The Telepresence Work 
System (TWS) will be incorporated, to complement or at least partially 
replace the EVA need, in this 1995-1997 time frame. Ultimately, the 
system will evolve to operate under teleautomation to further reduce 
the level of man-intensive supervision of the system. 


1991 

Jl° C 

19§3 - 

1 

1995 

1 

1997 

_J 

2000-beyond 

L 

i i i i r 


*0 MRMS (BASIC) 

- RMS 

- EXCHANGEABLE EE 


*0 MANNED PLATFORM(S) 

*0 TELEOPERATED (SS) 

• TELEOPERATED <GND) » 

- TIME DELAY 

• MRMS 

- TWO 20' ARMS 

- DUAL-ARM CONTROL 

- ADAPTIVE CONTROL 

- FORCE/TORQUE CONTROL 

• ADD 

- DEXTEROUS TWS ON 20' ARM(S) 

- LIMITED SUPERVISORY CONTROL 

• ADD 

- COORDINATED 
MULTIARM UNITS 

• ADD 

- TELEAUTOMATION 

•TECHNOLOGY EXISTS 

Figure 5-5 MRMS Program Evolution 
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5.2.2 Dual Astronaut Positioning Arms 

The first major growth modification anticipated of the MRMS Is the 
addition of two 20-foot arms to the payload platform layer. The size 
of the basic platform Is approximately nine feet square. It consists of 
three layers as shown In Figure 5-6. An artist Illustration of this 
concept Is shown In Figure 5-7. 

The bottom layer consists of a square track arrangement that rides on 
guide pins attached to. the truss nodes. The flat tracks are connected 
on the corners by "switches" that rotate 90°. The switches are 
aligned to permit motion over the guide pins In two orthogonal 
directions. The central element Is the push/ pull drive mechanism. It 
consists of a drawbar, with locking rods, connected to the MRMS by a 
rack and pinion drive. To pull the MRMS In a desired direction, the 
drawbar Is extended forward one bay to the next set of nodes and locked 
by driving the lock rods into the nodes. The corner switches* are 
aligned parallel to the movement of the vehicle. By actuating the 
electric motor, the MRMS is pulled by the drawbar along the tracks. To 
reverse directions, the MRMS pushes Itself. The vehicle is always 
captive to the truss structure by having four-point support maintained 
at all times. By repeating the process, the platform is translated 
longitudinally In an "inch-worm" fashion. 

Also required are Mobile Foot Restraint (MFR) positioning arms. 
Astronauts in EVA suits are positioned within their work envelope by 
these movable positioning arms. Control of the positioning arms and 
all. features of the MRMS optionally resides with the EVA astronaut(s) . 
These two positioning arms will be used on opposite sides of the space 
crane platform. The positioning arms have the freedom to translate 
along one side of the top layer. This capability greatly expands the 
work volume of the positioning arms as well as the astronaut. It also 
provides the option to have the astronauts work as a pair in a dual-arm 
mode. 
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Figure 5-6 Mobile Remote Manipulator System Elements 



Figure 5-7 MRMS Artist Concept ( Second Generation) 
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Figure 5-6 Mobile Remote Manipulator System Elements 
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The MRMS will have a self-contained, rechargeable power supply. 
Depending on the work and the mission, the platform frill be adaptable 

In terms of special storing devices and cradles for miscellaneous 

! 

hardware. 


5.2.3 Telepresence Effector Concept 


The second major growth modification to the expanding MRMS is the 
addition of a dexterous two armed EVA analog that can be transported 
around the station or crawl over the structure. Thi EVA astronaut or 
his replacement la an Integral part of assembly work and Is needed to 
accomplish the finer, precision tasks. There has been a considerable 
amount of discussion on the usage of EVA astronauts. The major problem 
Is the high cost of supporting a man, not to mention the risks 
Involved. An alternative to man will be a TWS (Telepresence Work 
System) at the end of the positioning arms, as shown In Figure 5-8. 

The TWS has the same or greater capabilities than man, yet reduces the 
amount of support equipment and preparatory work. An artist 
Illustration of this advanced concept Is shown In Figure 5-9. 
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5.3 AUTOMATION ASSESSMENT 

Implementation and evolution of automation on both the system and 
subsystem levels Is required to enable operational productivity In the 
Initial as veil as growth versions of the station. Increasing levels 
of automation over operational periods of 10-20 years will be driven by 
several factors: growth of the physical station, growth of the station 

operational complexity, Increasing Information workload, enhancements 
In computer capabilities, transition from a facility housekeeping 
priority mode to a payload Intensive operation environment, and to a 
more failure/malntecance conscious mode as the station ages. As 
Indicated above, productivity Is the major driver and results in a 
basic guideline to try and automate as many of the systems, subsystems 
and payloads as possible. 

Productivity as It applies here could take the form of reduced risk of 
human error, human safety, reduced crew time spent on laborious or 
monotonous tasks, thus freeing them for tasks requiring their unique 
capabilities, operating with reduced ground support crew and operating 
closer to optimum system performance efficiencies. 

Activities that make up these tasks In the area of assembly and 
construction include items such as material handling, joint fastening, 
beam adjustment and many others. The need for space automation in 
manned and unmanned space vehicles is really the need for solutions 
that use automation in whatever fashion or combination necessary to 
complete a job. The space operations philosophy to date has had humans 
with hands-on capability performing a large number of the automatable 
jobs. Past Implementation of automatic features consisted initially of 
a bottoms-up approach in which single components of automation were 
developed, followed by li;,V» v ed components of automation which were 
eventually combined into more complex systems progressing towards 
integrated solutions. 
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The emphasis of this study Is automation; however, the IOC space 
station will use the unique capabilities of man In the form of hands-on 
and remote control. Understanding and appreciation of these 
man/machine Interfaces are necessary to define the automation features 
and the degree of change with time. A simple model used to indicate a 
reference baseline is shown In Figure 5-10. 



Figure 5-10 Human Interactive Automation Model 


The area on the far right labeled spacecraft worksite and the 
mechanical hardware represents the space station structural components 
and the mobile remote manipulator system (MRMS) that were discussed in 
the prior section. The key to making this hardware operate comes under 
the direction of the man/machine (computers) combination. A proposed 
step partitioning in this area is shown In Figure 5-11. The capability 
to go directly from EVA/IVA hands-on to autonomous control can be 
accomplished usJ.ng todays technology or conventional automation. This 
Involves the extension and amplification of man's physical 
capabilities. However, to include the incorporation of man's mental 
capabilities requires a far more progressive approach, similar to that 
shown in Figure 5-11. 
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Figure 5-11 Remote Operations Transition Overview 

Shown on this schematic is a logical partitioning of capabilities In 
transitioning from an Intensive hands-on mode to an on-orblt autonomous 
mode. Terms used In establishing specific steps can be considered a 
subset of remote control. Conclce distinctions defining these evolving 
concepts are vague In many respects but do contain some specific 
capabilities that provide unique differences. 

For example, telepresence Is the most human Intensive control mode In 
this group, but It also provides fine dexterity at the worksite with 
minimal operator training. This capability Is extremely useful where 
the remote human operator has an ln-depth knowledge base relevant to 
the worksite, but little or no experience in teleoperation. 
Teleoperation provides for the reverse of telepresence In that the 
operator is skilled at receiving displayed data at the remote 
workstation and providing commands in response to displayed signals. 
Technology in the form of sensory perception has a considerable overlap 
or potential for technology transfer from one concept to the other. 
Sensors must be selected where the data feedback signals are compatible 
with either direct display through the video screen or to the computer 
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and adaptive control software. Both supervisory and teleautomation 
modes as defined here provide a progressively decreasing level of 
operator interactions. 


Using the steps developed and shown in Figure 5—11 and the basic 
philosophy flow of slowly transferring the human operator's physical 
interactions and mental capabilities from them to machines can be 
illustrated through the control environment. For purposes of this 
study, the control system evolution phase is divided into four major 
stages as displayed in Figure 5-12. Each stage in this control concept 
is represented by different shades in sequential time periods. A brief 
discussion of each stage is presented below: 



OFFLINE 


STRATEGIC 


TACTICAL 


EXEC. 


PROGRAMMING 


PLANNER 


PLANNER 


CONTROLLER 



Figure 5-12 Remote Control Automation Evolutionary Stages 
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Stage 1 

In the first stage, all manipulator actions are based upon controller 
Inputs. Manipulator position is a direct function of hand controller 
position. The prime method for operator sensing is through indirect 
vision (TV). Typical hand controllers used here Include switches, 
exoskeleton and replica types. 

Stage 2 

In the second stage of evolution, additional sensing of worksite 
activity is achieved through force and tactile sensors. The output of 
these sensors can be monitored by the operator through graphic displays 
or directly through the hand controller. In addition, the operator is 
aided by more advanced control laws that incorporate force information 
as well as adaplng to load changes. These advanced laws facilitate the 
control of two arms by one or two operators. 

Stage 3 

The third stage marks the beginning of the use of intelligent 
automation techniques. For single segments of a given task, the 
operator will have the capability for Initiating a "supervisory” mode 
in which the computer has the responsibility for executing the given 
task. The computer notifies the operator of task status, exception or 
fault conditions and task completion. Stereo vision or scanning laser 
data are processed and used in control algorithms to provide range data. 

Stage 4 

In the final stage of evolution, the operator specifies a class of 
tasks to be- performed. The computer plans the task, Including order of 
activities, tool selection and exception handling. The operator is 
notified only when workaround techniques fail. Visual data is used to 
a higher degree in both planning and execution. 
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Figure 5-13 shows the overall' control system evolution based on a time 
phase consistent with the simple mission model representing assembly 
and construction trends. The major evolutionary steps follow a logical 
waterfall schedule based on a sequential need priority and a technology 

development estimate. 
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Figure 5-13 Control System Evolution 

A technology assessment matrix was prepared using the Information 
generated In Figures 5-5 and 5-13. Figure 5-14 summarizes this data 
and Identifies the projected primary and ancillary technology drivers 
needing additional study, research, development and verification. The 
order in which they are listed reflects a priority ranking for 
development. This was done as part of the technology assessment effort 
where the priority ranking technique used depended on a simple 
comparison procedure. Each key technology was compared against a set 
of priority parameters. 
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Teleoperation (Remote Control! 
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Figure 5-14 Automation Technology Assessment 


The process used was to separate the least-preferred features from the 
most preferred features. A value of merit was assigned where the 
number ”1" Indicated the most preferred and went sequentially higher 
through to the least preferred. A final priority ranking Is presented 
in Table 5-3 that shows a numerical tally of all the Individual 
rankings with the lowest value having the top priority. This was a 
very quick look approach In that no weighting factors were applied. 

Each of the nine preference ranking parameters carried the same 
weighting factors, whereas In more complex assessment methods different 
weights might be applied to each comparison parameter. 


Due to the vagueness In this area, and In some cases a lack of 
comparison data, the results were Intended to show trends rather than 
exact conclusions. 
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Table 5-3 Technology Priority Comparison Matrix 


\ PRIORITY 

\ RANKING 

N. iraq^RiA 

SELECTED^^^^ 

TECHNOLOGY 

GROUP 

•I 

u 

a 

1 
t a. 

e " 

i 

3 

X 

1 

Ui 

H 

S 

SL 

M 

’5 

UJ 

A indication Frequency 

c 

,2 

1 

8 

. ,* 

! 

Development Cost 

Benefits 

Prior SRT Efforts 

Near-Term Development 
Need 

National Interest 

Final Priority Ranking 
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1 

6 

2 

2 

8 

Wa 

3 
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3 

Proximity, Touch & Force Sensors 

10 

6 

5 

1 

1 

5 
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1 

9 

2 

Teleoperations (Remote Control) 

5 

5 

2 

3 

3 
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4 

10 

1 

Advanced Actuators 

6 

4 
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6 

11 



2 

8 

6 

Low Weight<*Dexterous Arm 

7 

3 

1 

El 

5 

10 



5 

7 

4 

Dual Arm Coordination 

6 

2 

3 

6 

7 

6 



6 

5 

5 
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3 
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11 

9 

10 
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9 

2 

10 
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2 

8 

7 

10 

11 
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7 

4 

7 
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1 

10 

9 
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8 
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1 

9 
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7 

8 

7 
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11 

6 

11 
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4 

9 

10 

11 

9 
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10 

3 

8 
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— 

H 



12 



5.4 TECHNOLOGY DEVELOPMENT PLAN 

A cost effective and technically feasible automation development plan 
must consider a number of different disciplines and time related 
Impacts. Some of the major Items of considerable Importance In 
generating a development plan Include an understanding of the 
technology status, a sequential approach towards technology 
Implementation, and a logical evolution that provides options as a 
function of risk, safety and costs. The key technologies used In 
generating the plan are those Identified In Table 5-3 of the prior 
section. Table 5-4 shows the application of these key technologies to 
the generic list of ACSE. 
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Table 5-4 Technology and Equipment Matrix 
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13| Portable Control Box Pendant 
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14) Special Function Manipulators (5 DCF or less) 
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iS^jarousel Mechanism (satellite A stem Fix) 
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16) Structufespeployment Aid 
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17) Alignment & SiiHs.ce Accuracy Tools (Gross) 
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18) Alignment & Surface Accuracy Tools System 
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19} Checkout Tools (Mechanical. Elec't-Jfc Data) 
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20) Portable Deployable Sun Shade 
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21) Special Purpose End Effectors 
{Manipulator Exchange) 
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The Integration of these technologies 'into the assembly and 
construction support equipment development will be consistent with 
standard aerospace hardware development programs. However, early 
hardware development should take advantage of the NASA protoflight 
concept of early flight testing of systems and subsystems. This 
reduces the number of test hardware units, reduces the extent of ground 
testing and makes use of the Shuttle test bed concept where hardware Is 
tested in a structured space environment, then returned for post-test 
Inspections and analyses. With this programmatic philosophy. 
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all subsystems will be divided Into manned and unmanned elements. 

These manned elements Include Items such as the MRMS personnel and 

material transporters and the MFR (mobile foot restraint). Any Item 
with direct human Interaction or where crew safety could be at issue 
will receive more extensive ground testing to demonstrate flight 
worthiness. 

The unmanned elements, such as manipulators, docking devices, mobile 
transport platforms, lighting aid, alignment package, etc., will 
initially be evaluated from the Orbiter payload specialist station with 
the elements being captive within the cargo bay. The Shuttle remote 
manipulator system and EVA manned maneuvering unit will be utilized in 
these evaluations. 

After completion of proof-of-concept and subsystem tests, the various 
elements will be assembled on a priority step basis (greater system 
complexity) and ground tested to verify all interfaces. The new 
elements added into the system will then be functionally verified as a 
system through Space Station test bed Shuttle sortie flights, using 
task panels and structure mockups for operational simulations. This 
verification process will ensure the operational demonstration can be 
operated efficiently as part of an evolvability growth plan. 

After completion of the flight subsystem tests, the elements will be 
assembled and checked to verify all Space Station interfaces. Any 
inconsistencies will be updated and factored into the flight hardware 
fabrication cycle. 

A summary development and demonstration plan schematic is presented in 
Figure 5-15 that follows the various key technologies through the major 
fabrication and test cycles. This plan has been generated using five 
primary phases in the development and demonstration of selected 
assembly and construction support equipment (ACSE): 1) design study, 

2) proof of concept, 3) prototype or protoflight units, 4) Shuttle 
flight test bed, 5) systems integration, and 6) space flight operations 
verification. 
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6.0 TECHNOLOGY PROJECTIONS 
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The overall emphasis of this study was to project into the future and 
forecast technology requirements needed to adapt to the anticipated 
evolutionary growth of the Space Station. Many of these technology 
requirements were discussed in the previous sections, along with 
development plans. This section presents a summary of the technology 
developments for both system automation (or architecture) and assembly 
and construction, emphasing manipulation and associated technologies. 

The technology time phased summary for both areas is shown in Figure 
6-1. The center area of the figure represents the control element, 
which is common to both manipulation and system architecture. The 
anticipated time frames for development of ground and flight 
capabilities and future sophisticated capabilities are shown. 
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Figure 6-1 Technology Time Phase Summary 



